Linking other requests/discussions on the topic I could find:
#4133
#4076
#5023
#3124
#2749
#2268
#2901
#3220
#4284
#4133
#5140

Hi sergeyn,

I tried your code change and found one issue, the Plotting animation stops when the mouse moving is stopped. I donot think this is the expected result. Please check the original Plotting example.

IMOP, the power save mode should not break the animation or other dynamic UI changes.

@ForrestFeng - sure thing, thanks for reporting this. Fixed now.

@ocornut - Api function added ( ImGui::SetNextRefresh ) . But I'm sure you'll want to change things around whether you decide to get this in

@sergeyn thanks for fixing it.

I have one question:
What's the best way to implement a battery and clock display with the current power-saving API.

The battery requires a much lower refresh frequency. The clock requires 1 refresh per minute. A clock with the second digit requires 1 refresh per second.

What's the best way to handle the different refresh frequency requirements with the API. Thanks.

Can we control how many frames to redraw with the API. For example, when the time changes from 7:22 to 7:23 I just want to redraw 2 or 3 frames, I do not want to waste the power to refresh the GUI all the time just for this clock.

@sergeyn one more defect found that the scroll bar is not synchronized with content changes in the window.

Steps to recreate:

1. Open the Table Columns sample
2. Move the mouse over the Open All button
3. Left click (when click keep it in the same position)
4. You can see the content is expanded
   Expect:
   The scroll bar becomes shorter immediately
   Actual:
   The scroll bar keeps in the old status unless you move the mouse.

@ForrestFeng - fixed scrollbar issue. thanks for reporting.

@ForrestFeng - as for your refresh question, you need to compute how much time should pass before you'd have a frame with a changed clock arrow (at any point in time) and shove it into SetNextRefresh

auto NextRefreshDelayInSeconds = NextTimeMyFancyClockShouldTick_TimePoint - (ImGui::GetTime()-LastTimeMyFancyClockTicked_TimePoint); ImGui::SetNextRefresh(float(NextRefreshDelayInSeconds), "My Fancy Clock Just Moved");

Note that you actually need to do this computation, it's not enough to just set refresh delay (first parameter to SetNextRefresh) to 1.0f (for 1 second) because this way another random refresh (due to mouse move for example) happening mid-way through your second (or minute) would always offset your re-render by 1 second, and this is not what you want

@ocornut - I had to compute final window size at the End() to know if scroll bar potentially going to change next update. Not an ideal solution as I'd like to have it to be completely zero cost. Do you happen to know a better approach of knowing if the scorllbar going to change ?

Note that you actually need to do this computation, it's not enough to just set refresh delay (first parameter to SetNextRefresh) to 1.0f (for 1 second) because this way another random refresh (due to mouse move for example) happening mid-way through your second (or minute) would always offset your re-render by 1 second, and this is not what you want

I do not quite understand the logic. Can you let me know how the delay/API works? Can we just complete the goal with a simple API like RequestRepaint() without any parameter?

Thanks.

Note that you actually need to do this computation, it's not enough to just set refresh delay (first parameter to SetNextRefresh) to 1.0f (for 1 second) because this way another random refresh (due to mouse move for example) happening mid-way through your second (or minute) would always offset your re-render by 1 second, and this is not what you want

I do not quite understand the logic. Can you let me know how the delay/API works? Can we just complete the goal with a simple API like RequestRepaint() without any parameter?

Thanks.

If you want RequestRepaint without any parameter, you simply pass 0.0f, ""

Api is quite simple: with the first parameter you specify the maximum amount of seconds you want next update to be delayed by. If you put 2.0f there, that means if no other repaint events happen, you'll get your repaint in 2 seconds.
The last parameter is a string for debugging purposes. It'll be shown in the console as the repaint reason.

@sergeyn and @ocornut

I create another PR for power save working mode based on the idea of sergeyn. It is compatible with the old no-blocking drawing mode while providing flexibility to have the power save feature.

Could you take a look at it?

Thanks

It is compatible with the old no-blocking drawing mode while providing flexibility to have the power save feature.

Hi! Plz correct me if I'm wrong. The mechanics you propose with RequestRedraw is exactly the same as mine when zero delay passed as an argument (i.e. SetNextRefresh(0.0) ). As I understand it, your approach doesn't handle blinking cursor type of animation, where you need to redraw once about every second, unless you make blinking cursor redraw all the time.

Regards.

One more repaint optimization I'm thinking about is to track the rectangle of the currently hovered over window. Then within this rectangle mouse move events can be ignored. Given that mouse move events are the repaint reason in 99% of the cases, this would drastically reduce amount of repaints happening when you actually work with an application.

Are there any plans of this being officially implemented, for other APIs and for docking branch?

Thank you! For now I've limited my UI to 10fps, which seems good enough, and that has reduced GPU usage to "good enough" levels.